AI Agent Tool Permissions: Least-Privilege Checklist for 2026

Cover: A tool call becomes safe only after an explicit permission decision.

Figure: Classify permissions by side effect, not only by tool name.

What are AI agent tool permissions?

An AI agent does not become safe merely because its system prompt says “be careful.” The real security boundary is the action the agent can take: reading a customer record, sending an email, changing a database row, calling an external API, or delegating work to another agent.

Tool permissions are the rules that decide which actions an agent may request, under which identity, against which resources, with which arguments, and at what risk level. The most reliable design is to keep that decision outside the model’s free-form reasoning and enforce it at the tool boundary.

This guide presents a practical least-privilege checklist for AI agent tool permissions. It is written for developers, platform engineers, and security teams building tool-using or multi-agent systems. The examples are illustrative; they are not a substitute for testing a policy in the actual runtime, identity system, and data environment.

What “tool permission” actually means

Several controls are often mixed together, but they solve different problems.

A prompt can describe the desired behavior, but it is not an authorization system. OWASP’s agentic-AI guidance treats autonomous systems as a threat-modeling problem because the combination of model reasoning, external tools, and persistent state expands both capability and risk.[¹]

Why tool permissions are easy to get wrong

The request and the harm may be separated in time

An agent may receive a harmless-looking request now and use the resulting permission later, after the surrounding context has changed. This is why authorization needs scope, expiry, and an audit trail rather than a one-time prompt instruction.

A tool name hides different side effects

A function called `manage_customer` could read, edit, export, or delete data. Separate capabilities by side effect so a read-only workflow does not accidentally inherit write authority.

One broad identity creates hidden authority

If every workflow uses the same service account, the policy becomes difficult to reason about and a compromised agent can reach more resources than its task requires. Use distinct principals or narrowly scoped delegated capabilities.

The six-part permission model

A useful permission record is more specific than “the agent can use email.” Before allowing a call, answer six questions.

1. Which principal is acting?

Identify the agent, user, service, or delegated sub-agent behind the request. Do not use one all-powerful service account for every workflow. A research agent, a support triage agent, and a billing assistant should not automatically share the same identity or credentials.

The principal should be verifiable at the enforcement layer. The model’s statement that it is acting for a particular user is not proof of identity.

2. Which tenant and resources are in scope?

Permissions should name the tenant, project, account, repository, folder, or record set that may be accessed. Tenant isolation is especially important in multi-user systems: a valid read permission for one customer must not become a valid read permission for every customer.

Use narrow resource selectors where possible. “Read tickets in tenant acme” is safer than “read tickets.”

3. What action is requested?

Separate read, create, update, delete, execute, publish, and delegate actions. A tool name alone is not enough. A function called manage_customer may hide several very different operations with different risks.

Design tool schemas so the action is explicit. For example, draft_email and send_email should normally be different capabilities, even if they share implementation code.

4. Which arguments are allowed?

Authorization should consider the arguments, not only the function name. A read request for a public help article is different from a query for payroll records. A database update that changes one test row is different from an update with a wildcard filter.

Constrain identifiers, paths, recipients, amounts, query shapes, and destinations. Reject unexpected fields instead of silently ignoring them. Validate again at the tool boundary after the model has produced structured arguments.

5. How long and how much may it act?

Use short-lived credentials, request budgets, rate limits, and transaction limits. A permission that is safe for one call may become dangerous when repeated thousands of times. Time and quantity constraints reduce the blast radius of loops, retries, and compromised workflows.

For financial, deletion, or external-communication actions, define explicit thresholds and escalation rules. Never describe a threshold as universally safe; it depends on the application and its risk owner.

6. What decision and evidence are recorded?

Each call should resolve to a clear decision: allow, deny, or requires_approval. Record the identity, tool, resource scope, relevant argument summary or hash, policy version, timestamp, decision reason, and execution result. Do not place raw secrets or unnecessary personal data in the audit log.

Allow, deny, or human approval?

A small decision matrix makes a policy easier to review than a long prompt.

The important point is not that every write must be blocked. It is that the decision should be deliberate, explainable, and enforced consistently.

An illustrative permission manifest

A permission manifest can make the intended boundary reviewable. This example is deliberately small and contains no real credentials:

{
  "principal": "support-triage-agent",
  "tenant": "acme",
  "tools": {
    "search_tickets": {
      "actions": ["read"],
      "scope": "tenant:acme",
      "max_results": 20,
      "decision": "allow"
    },
    "draft_reply": {
      "actions": ["create"],
      "scope": "ticket:assigned",
      "decision": "allow"
    },
    "send_reply": {
      "actions": ["send"],
      "scope": "ticket:assigned",
      "decision": "requires_approval"
    },
    "delete_ticket": {
      "actions": ["delete"],
      "decision": "deny"
    }
  }
}

This manifest is not a complete authorization policy. In production, the runtime must verify the principal, resolve the real tenant and resource, validate arguments, and enforce the decision through a trusted component.

Enforce the decision before the tool call

The safest sequence is deterministic and short:

1. The model proposes a structured tool call.
2. The runtime normalizes the tool name and arguments.
3. The enforcement layer authenticates the principal and resolves the tenant.
4. The policy evaluates action, resource, arguments, time, and risk.
5. The system allows, denies, or pauses for human approval.
6. Only an allowed call reaches the tool.
7. The decision and outcome are logged.

This is the core idea behind pre-action authorization discussed in recent research: intercept and evaluate the individual call before execution, while treating sandboxing and model-based screening as complementary controls rather than replacements.[⁴]

The Vercel AI SDK documentation provides a practical example of policy-based tool approvals. Its policy interface can return allow, deny, or requires-approval, and its examples show how to deny a destructive command, allow read-only operations, and require approval based on runtime context.[³] The same pattern can be implemented with another policy engine or a carefully reviewed authorization service.

Figure: The policy decision belongs before execution.

Policy-as-code: a small example

Policy-as-code can make decisions versioned, reviewable, and testable outside the application’s conversational logic. The following Rego-like example is illustrative and intentionally incomplete:

package agent.call

default decision := {
  "decision": "deny",
  "reason": "no matching rule"
}

decision := {
  "decision": "allow",
  "reason": "read-only ticket search within tenant"
} if {
  input.tool.name == "search_tickets"
  input.args.tenant == input.runtimeContext.tenant
  input.args.limit <= 20
}

decision := {
  "decision": "requires-approval",
  "reason": "external communication needs review"
} if {
  input.tool.name == "send_reply"
  input.runtimeContext.approval_required == true
}

decision := {
  "decision": "deny",
  "reason": "destructive tool is disabled"
} if {
  input.tool.name == "delete_ticket"
}

The example uses default-deny because an unmatched call should not silently become allowed. A real policy must also validate the input shape, protect against confused-deputy behavior, handle approval freshness, and fail closed when the policy service is unavailable. Test the policy with safe fixtures before connecting it to production tools.

Figure: Use this checklist during a permission review before enabling an agent tool.

Testing checklist for an existing agent

Start with the tool inventory, not with the prompt. For each tool, document its action type, resource scope, credential, side effects, reversibility, and owner. Then test both the normal path and the boundary conditions.

The existing AI Evaluation Harness guide can help structure these cases as repeatable workflow tests. The AI Agent Observability playbook is useful for the telemetry and investigation side.

MCP and multi-agent boundaries

A permission check should happen at every trust boundary. If an agent calls an MCP server, the server and its methods need their own identity, scope, and policy checks. If one agent delegates to another, the child should receive a capability that is no broader than the parent’s current task.

Do not assume that a tool description, remote server name, or model-generated explanation is trustworthy evidence of authorization. Treat descriptions as input to validate, not as permission grants. The Model Context Protocol guide provides background on the protocol, while the AI Agent Identity article covers identity and zero-trust concepts that complement this tool-level boundary.

NIST’s AI Agent Standards Initiative describes work on industry standards, community protocols, research, and agent authentication and identity infrastructure. It also links to a draft concept paper on software and AI agent identity and authorization.[²] Because this landscape is still developing, teams should treat emerging guidance as input to their design rather than as a finished universal standard.

Common mistakes

The most common mistake is putting the entire permission model inside the system prompt. A prompt may help the model choose appropriate actions, but it cannot be the final enforcement point. Another mistake is granting a single agent a broad credential and expecting the model to self-limit.

Teams also often check only the tool name, not the arguments or resource scope. This can turn a harmless read function into a data-exfiltration path. Finally, a policy that allows unmatched calls, records raw secrets in logs, or grants a child agent the parent’s full authority can fail even when the individual tool implementation looks correct.

A practical first improvement is to separate tools by side effect: read, draft, send, mutate, delete, and delegate. Then create explicit decisions for each category and add tests for the most important tenant and argument boundaries.

What to do when a suspicious call is detected

Do not simply delete the log entry and continue. Quarantine the run, revoke or expire the affected capability, preserve the policy decision and relevant evidence, and determine whether a downstream action completed. If credentials or sensitive data may have been exposed, follow the organization’s incident-response process and rotate the affected secrets.

After recovery, add a regression test that reproduces the failed boundary. A security rule that exists only in an incident document is not yet an enforced control.

Frequently asked questions

Can a system prompt enforce tool permissions?

No. It can provide guidance, but the trusted runtime or authorization layer must enforce whether a call is allowed.

Should every tool call require a human?

No. Requiring approval for every low-risk read can make a system unusable. Use explicit risk tiers, allow narrowly scoped reversible actions, and require approval for consequential or externally visible actions.

What does default-deny mean?

It means a call is rejected unless a specific rule matches and allows it. This reduces the chance that a newly added tool or malformed request becomes available by accident.

Is sandboxing enough?

No. Sandboxing can reduce the blast radius of code execution, but it does not answer whether a particular business action is authorized. It works best alongside identity, policy, validation, and monitoring.

How should a team start?

Inventory the tools, separate read from write capabilities, identify the principal and tenant for each workflow, choose allow/deny/approval decisions, and test the highest-risk boundaries first.

Conclusion

AI agent tool permissions are not a cosmetic layer around a prompt. They are an authorization boundary between model output and real-world action. A least-privilege design names the principal, limits the tenant and resources, constrains arguments, controls time and quantity, chooses an explicit decision, and records evidence.

Start small: secure one workflow, split its read and write tools, default unmatched calls to deny, require approval for consequential actions, and add regression tests. Then expand the same pattern across MCP methods, APIs, and agent-to-agent delegation. This approach is more practical than promising perfect autonomy, and it gives the team a clear way to review what the agent can actually do.

Editorial note: The references below include OWASP guidance, NIST program information, public documentation, and a clearly identified research preprint. The code examples are illustrative and must be adapted and tested before production use.

References

1. OWASP, Agentic AI — Threats and Mitigations
2. NIST, AI Agent Standards Initiative
3. Vercel AI SDK, Policy-Based Tool Approvals
4. Uchi Uchibeke, Before the Tool Call: Deterministic Pre-Action Authorization for Autonomous AI Agents, arXiv